FIG. 1 shows a network structure of the E-UMTS, a mobile communication system, applicable to the related art and the present invention. The E-UMTS system has been evolved from the UMTS system, for which the 3GPP is proceeding with the preparation of the basic specifications. The E-UMTS system may be classified as the LTE (Long Term Evolution) system.
The E-UMTS network may be divided into an evolved-UMTS terrestrial radio access network (E-UTRAN) and a core network (CN). The E-UTRAN includes a terminal (referred to as ‘UE (User Equipment), hereinafter), a base station (referred to as an eNode B, hereinafter), a serving gateway (S-GW) located at a termination of a network and connected to an external network, and a mobility management entity (MME) superintending mobility of the UE. One or more cells may exist for a single eNode B.
FIGS. 2 and 3 illustrate a radio interface protocol architecture based on a 3GPP radio access network specification between the UE and the base station. The radio interface protocol has horizontal layers comprising a physical layer, a data link layer, and a network layer, and has vertical planes comprising a user plane for transmitting data information and a control plane for transmitting control signals (signaling). The protocol layers can be divided into the first layer (L1), the second layer (L2), and the third layer (L3) based on three lower layers of an open system interconnection (OSI) standard model widely known in communication systems.
The radio protocol control plane in FIG. 2 and each layer of the radio protocol user plane in FIG. 3 will now be described.
The physical layer, namely, the first layer (L1), provides an information transfer service to an upper layer by using a physical channel. The physical layer is connected to an upper layer called a medium access control (MAC) layer via a transport channel, and data is transferred between the MAC layer and the physical layer via the transport channel. Meanwhile, between different physical layers, namely, between a physical layer of a transmitting side and that of a receiving side, data is transferred via a physical channel.
The MAC layer of the second layer provides a service to a radio link control (RLC) layer, its upper layer, via a logical channel. An RLC layer of the second layer may support reliable data transmissions. A PDCP layer of the second layer performs a header compression function to reduce the size of a header of an IP packet including sizable unnecessary control information, to thereby effectively transmit an IP packet such as IPv4 or IPv6 in a radio interface with a relatively small bandwidth.
A radio resource control (RRC) layer located at the lowest portion of the third layer is defined only in the control plane and handles the controlling of logical channels, transport channels and physical channels in relation to configuration, reconfiguration and release of radio bearers (RBs). The radio bearer refers to a service provided by the second layer (L2) for data transmission between the UE and the UTRAN.
A random access channel (RACH) will now be described. The RACH is used to transmit data with a relatively short length to uplink, and in particular, the RACH is used when a UE, which has not been allocated dedicated radio resources, has a signaling message or user data to be transmitted to uplink. Or, the RACH may be also used for a base station to instruct a UE to perform a RACH procedure.
A random access channel (RACH) procedure provided by the LTE system will now be described. The RACH procedure provided by the LTE system is divided into a contention-based RACH procedure and a non-contention-based RACH procedure. The contention-based RACH procedure and the non-contention-based RACH procedure are determined based on whether or not a random access preamble used in a RACH procedure has been directly selected by a UE or by a base station.
In the non-contention-based RACH procedure, the UE uses a random access preamble the base station has directly allocated to the UE. Thus, when the base station allocates the particular random access preamble only to the UE, the random access preamble is used by only the UE while other UEs do not use it. Thus, a one-to-one relationship is established between the random access preamble and the UE using the random access preamble, so there is no collision. This is effective because the base station can recognize the UE that has transmitted the random access preamble upon receiving the random access preamble.
Meanwhile, in the contention-based RACH procedure, the base station selectively transmits one of random access preambles, so there is a possibility that a plurality of UEs may use the same random access preamble. Thus, when the base station receives a certain particular random access preamble, it cannot recognize which UE has transmitted the random access preamble.
In general, the UE may perform the RACH procedure in the following cases: 1) when the UE performs initial accessing because it is not RRC-connected with the base station, 2) when the UE is first connected to a target cell during a handover process, 3) when the RACH procedure is requested by an instruction of the base station, 4) when data to uplink is generated in a state that time synchronization of uplink is not matched or in a state that designated radio resources used for requesting radio resources have not been allocated, and 5) when a recovery process is performed in case of a radio link failure or a handover failure.
FIG. 4 shows operations of the UE and the base station in the contention-based RACH procedure.
First, in the contention-based random access, the UE randomly selects one random access preamble from a set of random access preambles instructed by system information or a handover command, selects PRACH resource that can transmit the random access preamble, and transmits the same (first step). The preamble at this time is called an RACH MSG 1.
After transmitting the random access preamble, the UE attempts receiving of a response to its random access preamble within a random access response reception window instructed by the system information or the handover command (second step). In more detail, random access response information is transmitted in the form of MAC PDU, and the MAC PDU may be transferred via a physical downlink shared channel (PDSCH). In addition, in order for the UE to properly receive information transmitted via the PDSCH, a physical downlink control channel (PDCCH) is also transferred. Namely, the PDCCH may include information about the UE which is to receive the PDSCH, frequency and time information of radio resources of the PDSCH, a transmission format of the PDSCH, and the like. Here, when the UE successfully receives the PDCCH which has been transmitted thereto, it properly receives the random access response transmitted via the PDSCH according to the information of the PDSCH. The random access response includes a random access preamble identifier (ID), a UL grant (uplink radio resources), a temporary C-RNTI (temporary cell identifier), and a time alignment command (time synchronization correction value). The reason why the random access preamble ID is required is because one random access response may include random access response information for one or more UEs, so the random access preamble ID informs about for which UE the UL grant, the temporary C-RNTI and the time alignment command information are valid. The random access preamble ID is identical to the random access preamble that has been selected by the UE itself.
Here, when the UE receives the random access response valid for the UE itself, the UE processes information included in the random access response. Namely, the UE applies the time alignment command and stores the temporary C-RNTI. In addition, the UE transmits data stored in its buffer or newly generated data to the base station (third step). In this case, data (referred to as ‘MSG 3’, hereinafter) included in the UL grant should necessarily include an identifier of the UE. The reason is because, in the contention-based RACH procedure, the base station can hardly determine which UEs perform the RACH procedure, and it should identify UEs to prevent occurrence of collision. Here, there are two methods for including the ID of the UE. The first method is that when the UE already has a valid cell ID which has been allocated in a corresponding cell before the RACH procedure, the UE transmits its cell ID via the UL grant. If, however, the UE has not been allocated a valid cell ID before the RACH procedure, the UE includes its unique ID (e.g., an S-TMSI or a random ID) and transmits the same. In general, the unique ID is longer than the cell ID. In the third step, when the UE transmits data via the UL grant, the UE starts a contention resolution timer.
After the UE transmits the data including its ID via the UL grant included in the random access response, the UE waits for an instruction of the base station to resolve contention. Namely, the UE attempts receiving of the PDCCH to receive a particular message (a fourth step). Here, there are two methods for receiving the PDCCH. As mentioned above, if the identifier of the UE transmitted via the UL grant is a cell ID of the UE, the UE attempts receiving of the PDCCH by using its cell ID, and if the identifier is its unique ID, the UE attempts receiving of the PDCCH by using the temporary C-RNTI included in the random access response. Thereafter, in the former case, if the UE receives the PDCCH (referred to as ‘MSG 4’, hereinafter) via its cell ID before the contention resolution timer expires, the UE determines that the RACH procedure has been normally performed, and terminates the RACH procedure. In the latter case, if the PDCCH is received via the temporary cell ID before the contention resolution timer expires, the UE checks data (referred to as ‘MSG 4’, hereinafter) transferred by the PDSCH indicated by the PDCCH. If content of the data includes its unique ID, the UE determines that the RACH procedure has been normally performed and terminates the RACH procedure. Here, the message or the MAC PDU received in the fourth step is usually called RACH MSG 4.
A method for receiving downlink data by the UE in the LTE system will now be described. FIG. 5 illustrates allocation or radio resources according to the related art.
In the downlink direction, physical channels are divided into the physical downlink control channel (PDCCH) and the physical downlink shared channel (PDSCH). The PDCCH is not directly related to transmission of user data and transmits control information required for operating a physical channel. Briefly, the PDCCH may be used to control other physical channels. In particular, the PDCCH is used to transmit information required for receiving the PDSCH. Information such as for which UE data is designated to be transmitted by using a particular frequency band at a particular point, which size of data is transmitted, and the like, is transmitted via the PDCCH. Thus, each UE receives the PDCCH at a particular TTI and checks whether or not data to be received by the UE is transmitted via the PDCCH. If it is informed that data to be received by the UE is transmitted, the UE additionally receives the PDSCH by using information such as frequency indicated by the PDCCH. Information about to which UE (one or a plurality of UEs) data of the PDSCH is transmitted or how the UEs receive the PDSCH data and decode it, and the like, may be included in a physical PDCCH and transmitted.
For example, it is assumed that, in a particular sub-frame, radio resource information (e.g., a frequency position) called ‘A’ and transmission format information (e.g., transport block size, modulation and coding information, etc.) called ‘B’ are CRC-masked to an RNTI (Radio Network Temporary Identity) called ‘C’, and transmitted via the PDCCH. One or two or more UEs located in a corresponding cell monitor the PDCCH by using their RNTI information, and on the above assumption, when the UE having the RNTI called ‘C’ decodes the PDCCH, a CRC error does not occur. Thus, the UE decodes the PDSCH to receive the data by using the transmission format information called ‘B’ and the radio resource information called ‘A’. Meanwhile, on the above assumption, if the UE does not have the RNTI called ‘C’, when the PDCCH is decoded, a CRC error occurs. Thus, the UE does not receive the PDSCH.
In the above procedure, the RNTI (Radio Network Temporary Identifier) is transmitted to inform to which UEs radio resources have been allocated. The RNTI includes a dedicated RNTI and a common RNTI. The dedicated RNTI is allocated to a single UE and used to transmit/receive data corresponding to the UE. The dedicated RNTI is allocated only to a UE whose information has been registered in the base station. Meanwhile, the common RNTI is used when UEs, which have not been allocated the dedicated RNTI because their information was not registered to the base station, transmit or receive data to or from the base station, or the common RNTI is used to transmit information commonly applied for a plurality of UEs.
First, the structure of the MAC PDU (Medium Access Control Protocol Data Unit) used for a MAC entity will now be described. FIG. 6 shows a format of the MAC PDU used for the MAC entity. In FIG. 6, an LCID informs to which logical channel a corresponding MAC SDU corresponds, and ‘L’ field informs about the size of the corresponding MAC SDU. An ‘E’ field informs whether or not there are additional headers. In the process, if the size of the corresponding MAC SDU or a MAC control element is larger than 127, the ‘L’ field of 15 bits is used. For a MAC sub-header with respect to the MAC SDU included in a MAC PDU or for a size-fixed MAC control element, a MAC sub-header in the form as shown in FIG. 7(b) is used. For other cases, a MAC sub-header in the form as shown in FIG. 7(a) is used.
Each field as used in FIG. 6 will now be described in detail as follows.                LCID: It informs about a logical channel to which a corresponding MAC SDU belongs, or which information a corresponding MAC CE (MAC Control Element) includes.        E: It informs about whether or not there is another MAC sub-header after the current MAC sub-header.        F: It informs about the length of a subsequent ‘L’ field.        R: It is a reserved bit which is not in use.        
Here, information about the values used for the LCID may be shown as the below tables.
TABLE 1LCKD values for DL-SCHIndexLCID values00001-xxxxxIdentity of the logicalchannelxxxxx-11011Reserved11100UE Contention ResolutionIdentity11101Timing Advance11110DRX Command11111Padding
TABLE 2LCID values for UL-SCHIndexLCID values00000-yyyyyIdentity of the logicalchannelyyyyy-11011Reserved11100Power Headroom Report11101Short Buffer Status Report11110Long Buffer Status Report11111Padding
In general, when a call starts, a UE, which has not made an RRC connection, should make the RRC connection with a base station. At this time, the UE performs the RACH procedure. For a UE, which has made the RRC connection but there is no uplink radio resources allocated to the UE, if data is generated, the UE should perform the RACH procedure. In the two cases, the UE configures a MAC PDU with a size corresponding to information included in the random access response received in the second step of the RACH procedure based on the information, and transmits the MAC PDU to the base station by using radio resources indicated by the information. In this case, a total amount of data, namely, the size of the MAC PDU, the UE can transmit in the uplink direction is substantially 56 bits. In addition, the RRC message initially transmitted by the UE, which is not in the RRC-connected state, is an RRC connection request message with a size of substantially 56 bits The RRC message is delivered in the form of MAC SDU to the MAC layer via the RLC layer. In order to configure the MAC PDU, a MAC header and a MAC SDU are required, and in this case, a minimum size of the MAC header is, if a single MAC sub-header is considered, 8 bits. Accordingly, when the MAC PDU including only the RRC connection request message is configured, it has the minimum 64 bits, which is larger than the message that can be transmitted in the third step of the RACH procedure.
The message transmitted by the RRC-connected UE to request allocation of radio resources from the base station is a buffer status report (BSR). There are two types of BSRs, of which a larger one has 32 bits including the MAC sub-header. Also, the UE should send its information to the base station, and it is a MAC C-RNTI CE (Control Element) which has 24 bits including the MAC sub-header. Thus, the size of the configured MAC PDU is 56 bits, and the MAC PDU can be transmitted in the third step of the RACH procedure.
In the third step of the RACH procedure, in order to transmit the RRC connection request message, 1) the size of the MAC PDU that can be transmitted in the third step of the RACH procedure should be increased, or 2) the size of the RRC connection request message should be reduced. In this case, however, when the size of the MAC PDU that can be transmitted in the third step of the RACH procedure is increased by 64 bits, the UE in the RRC-connected state should unnecessarily include 8 its in the MAC PDU. Also, when the size of the RRC connection request message is reduced, the UE should perform another RACH procedure to send remaining information, lengthening time for performing the RRC connection. In the process, when the RRC connection request message is included in the MAC PDU, the MAC PDU could be configured according to the limitation of 56 bits without the MAC sub-header, but then, when a receiving side receives the MAC PDU, it cannot know whether or not the MAC PDU includes the RRC connection request message or the BSR.